Co-existence mechanism for downloadable voice application client

ABSTRACT

A method for call processing comprising processing telecommunications data with an Over-The-Top (OTT) client on a handset, determining whether to use a voice over long term evolution (VoLTE) client or a WiFi client in response to an operational change and reconfiguring the handset to use the VoLTE client or the WiFi client if the determination is made to use the VoLTE client or the WiFi client, respectively.

RELATED APPLICATIONS

The present application claims priority to U.S. Provisional PatentApplication No. 62/266,325, filed Dec. 11, 2015, which is herebyincorporated by reference for all purposes, as if set forth herein inits entirety.

TECHNICAL FIELD

The present disclosure relates generally to telecommunications, and morespecifically to a co-existence mechanism for an Over-The-Top (OTT)downloadable voice application client and native embedded Voice over LTE(VoLTE) client or Voice over WiFi (VoWiFi) client in a mobile operatornetwork.

BACKGROUND OF THE INVENTION

Systems and methods for call setup and routing are known. In a systemthat includes a cellular services provider that use the Long TermEvolution (LTE) standard or for devices that are compatible with WiFi orother network standards, an OTT downloadable voice client can beinstalled by the user, where OTT refers to voice and data that istransmitted over the Internet packet switched network and withoutcarrier involvement in quality of service or call management, but thesedownloadable voice clients are not compatible with network calls.

SUMMARY OF THE INVENTION

A system and method for call processing is disclosed that includesprocessing telecommunications data with an OTT client on a handset, suchas by downloading the client, configuring the client, and sending orreceiving a call with the client. It is then determined whether to use aVoLTE client or a WiFi client in response to an operational change. Thehandset is reconfigured to use the VoLTE client or the WiFi client ifthe determination is made to use the VoLTE client or the WiFi client,respectively.

Other systems, methods, features, and advantages of the presentdisclosure will be or become apparent to one with skill in the art uponexamination of the following drawings and detailed description. It isintended that all such additional systems, methods, features, andadvantages be included within this description, be within the scope ofthe present disclosure, and be protected by the accompanying claims.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Aspects of the disclosure can be better understood with reference to thefollowing drawings. The components in the drawings may be to scale, butemphasis is placed upon clearly illustrating the principles of thepresent disclosure. Moreover, in the drawings, like reference numeralsdesignate corresponding parts throughout the several views, and inwhich:

FIG. 1 is a diagram of a system for providing third-party messaging,voice and video calling clients, in accordance with an exemplaryembodiment of the present disclosure;

FIG. 2 is a diagram of an algorithm for initial registration of an OTTclient, in accordance with an exemplary embodiment of the presentdisclosure;

FIG. 3 is a diagram of an algorithm for registering a VoLTE client orVoWiFi client after an OTT client registers, in accordance with anexemplary embodiment of the present disclosure;

FIG. 4 is a diagram of an algorithm for registering a VoLTE client or aVoWiFi client when an OTT client has already registered and is on avoice call, in accordance with an exemplary embodiment of the presentdisclosure;

FIG. 5 is a diagram of an algorithm for supporting a transition from anative VoLTE client to an OTT client as a result of a coverage change,in accordance with an exemplary embodiment of the present disclosure;and

FIG. 6 is a diagram of an algorithm for processing an incoming call whena native VoLTE client enters into an LTE service area and an OTT clientis engaged in a call, in accordance with an exemplary embodiment of thepresent disclosure.

DETAILED DESCRIPTION OF THE INVENTION

In the description that follows, like parts are marked throughout thespecification and drawings with the same reference numerals. The drawingfigures may be to scale and certain components can be shown ingeneralized or schematic form and identified by commercial designationsin the interest of clarity and conciseness.

As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

As used herein, “hardware” can include a combination of discretecomponents, an integrated circuit, an application-specific integratedcircuit, a field programmable gate array, or other suitable hardware. Asused herein, “software” can include one or more objects, agents,threads, lines of code, subroutines, separate software applications, twoor more lines of code or other suitable software structures operating intwo or more software applications, on one or more processors (where aprocessor includes one or more microcomputers or other suitable dataprocessing units, memory devices, input-output devices, displays, datainput devices such as a keyboard or a mouse, peripherals such asprinters and speakers, associated drivers, control cards, power sources,network devices, docking station devices, or other suitable devicesoperating under control of software systems in conjunction with theprocessor or other devices), or other suitable software structures. Inone exemplary embodiment, software can include one or more lines of codeor other suitable software structures operating in a general purposesoftware application, such as an operating system, and one or more linesof code or other suitable software structures operating in a specificpurpose software application. As used herein, the term “couple” and itscognate terms, such as “couples” and “coupled,” can include a physicalconnection (such as a copper conductor), a virtual connection (such asthrough randomly assigned memory locations of a data memory device), alogical connection (such as through logical gates of a semiconductingdevice), other suitable connections, or a suitable combination of suchconnections.

Today, there are many OTT third party client applications on the marketthat can provide voice, messaging and video capabilities to mobilecustomers. Some third party applications even offer an integrated dialeruser interface to provide a seamless voice calling experience to endusers, as if they are calling from a native embedded voice dialer on thehandsets. These third party systems suffer from many problems, primarilyin regards to service reliability and support. A cellular serviceprovider is in a position to offer better service reliability andsupport in conjunction with an OTT client application, by integratingthe OTT client application functionality with a native VoLTE client orVoWiFi client that is provided with the handset, either by the originalequipment manufacturer (OEM) or the cellular service provider, such thatthe handset can switch seamlessly between different media and systemfunctionalities. In this manner, a user making a call or using otherservices will not suffer interruption and will have greater satisfactionand security than can be offered by other OTT service providers. The OTTapplication can be offered by the cellular service provider, thecellular service provider can allow OTT application providers tointeract with the cellular service provider's carrier controlledenvironment, or other configurations can be used to provide thedisclosed system functionality.

FIG. 1 is a diagram of a system 100 for providing third-party messaging,voice and video calling clients, in accordance with an exemplaryembodiment of the present disclosure. System 100 allows user devices tocommunicate with an application server, such as one that is located in athird party controlled environment or that can be hosted by the cellularservices provider, using the data network provided by the wirelessoperators as underlying infrastructure.

System 100 includes handset 102, which can be a user device such as asmart phone, a smart watch, a tablet computer or other suitable devicesthat are used to communicate audio data, video data or other suitabledata. Handset 102 includes OTT client 110, VoLTE client 112 and VoWiFiclient 114, each of which can be implemented in hardware or a suitablecombination of hardware and software. OTT client 110 can be provided bya third party or the cellular service provider, but VoLTE client 112 andVoWiFi client 114 are typically provided by the OEM or the cellularservice provider.

Handset 102 is coupled to carrier controlled environment 104 overcommunications medium 132, which can be a WIFI network, an LTE network,an Internet network, an Ethernet network, other suitable communicationsmedia or a suitable combination of such communications media. Carriercontrolled environment 104 includes carrier OTT server 116 and carriercore network 118, each of which can be implemented in hardware or asuitable combination of hardware and software. Carrier OTT server 116can provide OTT client 110 services when those services are hosted bythe cellular services provider, or can provide support for third partyOTT service providers when they are authorized by the cellular servicesprovider. Carrier core network 118 provides core network functionality,including base station radio network functionality, base stationcontroller (BSC) functionality, mobile switching center (MSC)functionality and other carrier core network functionality.

Carrier controlled environment 104 is coupled to third party system 106over communications medium 134, which can be a tier 1 network, a tier 2network, a tier 3 network or other suitable communications media, asdiscussed above. Third party system 106 includes session server 120,voice over Internet protocol (VOIP) and IMS server 122, autoconfiguration server 124 and other suitable servers that are used tosupport OTT client 110, each of which can be implemented in hardware ora suitable combination of hardware and software.

Third party system 106 is coupled to provisioning system 108 overcommunications medium 136, which can be a tier 1 network, a tier 2network, a tier 3 network or other suitable communications media, asdiscussed above. Third party system 106 includes business support system126 and operation support system 128, each of which can be implementedin hardware or a suitable combination of hardware and software.

System 100 can be implemented in accordance with the 2G/3G/4G cellularnetwork, a WiFi data network or other suitable networks as describedabove, and is configured to operation in a manner that is transparent toOTT client 110, VoLTE client 112 or VoWiFi client 114. Handset 102 cancommunicate with third party system 106 or other suitable systems usinga virtual private network, encryption for security, or in other suitablemanners.

A cellular operator can use carrier controlled environment 104 or othersuitable systems to provide OTT messaging, voice and video callingapplications using OTT client 110, VoLTE client 112 and VoWiFi client114, by coupling those clients to compete with third party applicationproviders.

System 100 provides an integrated solution with OTT client 110, VoLTEclient 112 and VoWiFi client 114 of handset 102, using carriercontrolled environment 104, third party system 106 and provisioningsystem 108 and their associated component systems. In system 100,handset 102 uses the same Mobile Station International SubscriberDirectory Number (MSISDN), which is effectively a telephone number thatuniquely identifies handset 102, to make and receive calls, whether thecall is going through the cellular voice network, such as carriercontrolled environment 104, using a traditional original equipmentmanufacturer (OEM) client such as VoLTE client 112, or through thecellular network or a wireless data network, using OTT client 110 orVoWiFi client 114. A call can be initiated from any suitable control,regardless of whether it is a control from the OEM or one that isprovided by an application. For example, an OEM device can be providedwith a green “talk” button that can be used to instantiate a datacommunications session, and OTT client 110, VoLTE client 112 and/orVoWiFi client 114 can intelligently choose the correct communicationsmedium based on predefined criteria, by implementing the algorithmiccontrols disclosed herein or other suitable variations of those controlsthat fall within the scope of the claims.

The disclosed architecture provides for improved session mobility overprior art systems, which typically do not provide for any sessionmobility at all. Because the same core network is used, a transitionfrom a call that is placed over a WiFi network to a call on the LTEnetwork can be accomplished, because the different calling systems canbe coordinated. Thus, when a user places a call over a WiFi network,such as when the user is at home and is using a secure WiFi network inorder to place a call using a less expensive calling mechanism, the usercan then leave the secure WiFi environment and continue the call in theLTE environment without dropping the call.

In addition, a handset 102 that does not have built-in voice callingcapabilities, such as a tablet computer, can be connected to thecellular network for services such as messaging, voice calling and videocalling, and can receive an officially allocated MSISDN that allows thehandset 102 to be located by a caller using existing infrastructuresystems, such as the cellular service provider BSCs and MSC, and doesnot require the caller to have a third party application or to beconfigured to communicate over the third party application, such as toknow the called party's unique identifier for that third partyapplication.

Using a cellular call processing system service such as instantmessaging presents an implementation challenge when end users downloadOTT client 110 to a handset 102 that already has an OEM/native embeddedVoLTE client 112 or VoWiFi client 114 installed. Since both OTT client110 and VoLTE client 112 or VoWiFi client 114 register into the samecellular IMS system using the same MSISDN number, an additionalco-existence mechanism is needed at handset 102 to provide for seamlesstransitioning, reliability and security, as well as to provide andcontrol the terms and conditions by which handset 102 will interact withthe cellular system, to allow the cellular system to route a receivedcall and to determine which client to use for the end users to make acall. For example, if a handset 102 is in an LTE service zone, a callerneeds to be able to locate that handset, and then if the handset 102transits into a WiFi zone during that call, the handset 102 needs to beable to maintain the call without service interruption. Thedetermination of priority and all associated signaling and routingmechanisms related to the mobile cellular core IMS networks to make theend customer's voice calling experience seamless is provided by thepresent disclosure.

In order to accomplish this objective, VoLTE client 112 or VoWiFi client114 can take priority over OTT client 110, and OTT client 110 can detectand disengage when VoLTE client 112 or VoWiFi client 114 is registeredwith the same user in the mobile network. OTT client 110 over WiFiaccess can be registered at the same time when VoLTE client 112 has alsoregistered. However, whenever VoWiFi client 114 is registered, OTTclient 110 can either not register, de-register or can take otherappropriate actions to prevent misoperation.

FIG. 2 is a diagram of an algorithm 200 for initial registration of anOTT client, in accordance with an exemplary embodiment of the presentdisclosure. Algorithm 200 can be implemented in hardware or a suitablecombination of hardware and software.

Algorithm 200 can be utilized when an end user launches an OTT client onthe handset where a native VoLTE client or VoWiFi client have alreadyregistered, where the handset is an LTE-only handset and has no voicecapability, or in other suitable manners. After an identification of theassociated system components, those system components utilize thedisclosed algorithm to implement the calling environment. Algorithm 200is exemplary, and other suitable steps, processes, procedures orapplications can be utilized in conjunction with the associated processsteps.

Algorithm 200 begins at 202, where a client OTT application is initiatedon a handset, such as in conjunction with an associated OTT server,carrier core network components, a session server, a VOIP/IMS server, anauto configuration server, a business support system, an operationsupport system or other suitable systems, and a network access type isdetermined, such as an LTE or WiFi network. In one exemplary embodiment,a system such as system 100 can be utilized, and a device such ashandset 102 using OTT client 110 operating in conjunction with otherdisclosed system components can be used to determine the network accesstype, or other suitable processes can also or alternatively be used. TheOTT client will typically be configured by the OTT server, but can alsoor alternatively be configured by the carrier core network components, asession server, a VOIP/IMS server, an auto configuration server, abusiness support system, an operation support system or other suitablesystems, and location of this algorithmic function in any of thosesystem components is contemplated by the present disclosure. Thesecomponents can also or alternatively be used to implement thealgorithmic components of the disclosed algorithms, as would beunderstood by one of ordinary skill, and this will not be repeated foreach algorithm component. For example, a business support system 126, anoperation support system 128 or other systems can be involved with theinitiation of the OTT client, and may be called as part of theinitiation process, unlike the prior art, which might only utilize asession server, a VOIP/IMS server, and an auto configuration server toconfigure the OTT client. By coordinating the initiation of the OTTclient with the other system components, the remaining algorithmic stepscan be performed. The algorithm then proceeds to 204.

At 204, the client application registers with the mobile network andsubscribes to a registration event to get network notifications. In oneexemplary embodiment, the subscription can be performed using carrierOTT server 116, carrier core network 118, business support systems 126,operation support system 128 or other suitable system components asdescribed herein. The algorithm then proceeds to 206.

At 206, it is determined whether a native voice client has already beenregistered for the same user. For example, a native voice client such asVoLTE client 112 or VoWiFi client 114 of handset 102 can already havebeen registered, or other suitable native voice clients can already havebeen registered, and this is determined, such as at handset 102, carriercore network 118, business support systems 126, operation support system128 or other suitable system components as described herein If it isdetermined that a native voice client has not registered, the algorithmproceeds to 212 where the current registration of the OTT client ismaintained. Otherwise the algorithm proceeds to 208.

At 208, it is determined whether the native voice client is a VoLTEclient, such as VoLTE client 112, or a VoWiFi client, such as VoWiFiclient 114. If it is determined that the native voice client is a VoWiFiclient, such as at handset 102, carrier core network 118, businesssupport systems 126, operation support system 128 or other suitablesystem components as described herein, the algorithm proceeds to 214where the OTT client deregisters. Otherwise, the algorithm proceeds to210.

At 210, it is determined whether the native voice client is using LTEaccess or WiFi access, such as at handset 102, carrier core network 118,business support systems 126, operation support system 128 or othersuitable system components as described herein. Likewise, other suitabledeterminations can be made, based on the type of wireless accessavailable at the time or in the specific geographic location. If it isdetermined that the access mode is WiFi, the algorithm proceeds to 212where the OTT client is maintained. Otherwise, the algorithm proceeds to216, where the OTT client de-registers. In addition, the handset can“permanently” de-register the OTT client for LTE network access, such asby setting a suitable state variable or in other suitable manners.

Although algorithm 200 is shown in flow chart format, one of ordinaryskill will understand that object oriented programming, state transitiondiagrams or other suitable programming paradigms can also oralternatively be used.

FIG. 3 is a diagram of an algorithm 300 for registering a VoLTE clientor VoWiFi client after an OTT client registers, in accordance with anexemplary embodiment of the present disclosure. Algorithm 300 can beimplemented in hardware or a suitable combination of hardware andsoftware.

Algorithm 300 can be used when a client such as OTT client 110 hasalready registered, and the native VoLTE client or VoWiFi client entersinto LTE coverage or WiFi coverage. Algorithm 300 identifies theassociated system components, and algorithmic processes that areperformed by those system components, using algorithms implemented inhardware or a suitable combination of hardware and software. The diagramis exemplary, and other suitable steps, processes, procedures orapplications can be utilized in conjunction with the associated processsteps.

Algorithm 300 begins at 302, where a client application is initiated anda network access type is determined, such as an LTE or WiFi network. Inone exemplary embodiment, a system such as system 100 can be utilized,and a device such as handset 102 using OTT client 110, carrier corenetwork 118, business support systems 126, operation support system 128or other suitable system components as described herein can be used todetermine the network access type, or other suitable processes can alsoor alternatively be used. The algorithm then proceeds to 304.

At 304, the client application registers with the mobile network andsubscribes to a registration event to get network notifications. In oneexemplary embodiment, the subscription can be performed using carriercore network 118, business support systems 126, operation support system128 or other suitable system components as described herein. Thealgorithm then proceeds to 306.

At 306, it is determined that no VoLTE client or VoWiFi client hasregistered for the same user, such as at handset 102, carrier corenetwork 118, business support systems 126, operation support system 128or other suitable system components as described herein, and thealgorithm proceeds to 308, where the registration is maintained. Thealgorithm then proceeds to 310.

At 310, the handset is moved into an LTE coverage area or a trusted WiFicoverage area, which can trigger the VoLTE client or the VoWiFi clientto register, respectively. Registration can be performed using handset102, carrier core network 118, business support systems 126, operationsupport system 128 or other suitable system components as describedherein. After the registration process is initiated, the algorithmproceeds to 312.

At 312, the network sends a registration event, such as by using carriercore network 118, business support systems 126, operation support system128 or other suitable system components as described herein, which alsonotifies the OTT client that the other client (the VoLTE client or theVoWiFi client) has initiated registration. The algorithm then proceedsto 314.

At 314, it is determined whether the client that is attempting toregister is a VoLTE client 112 or VoWiFi client 114 of handset 102, orother suitable native voice clients can also or alternativelyregistered, and this can be determined at handset 102, carrier corenetwork 118, business support systems 126, operation support system 128or other suitable system components as described herein. If it isdetermined that the client is a VoWiFi client, the algorithm proceeds to318 where the OTT client de-registers. Otherwise the algorithm proceedsto 316.

At 316, it is determined whether the native voice client, such as OTTclient 110, is using LTE access or WiFi access, such as by handset 102,carrier core network 118, business support systems 126, operationsupport system 128 or other suitable system components as describedherein. Likewise, other suitable determinations can be made, based onthe type of wireless access available at the time or in the specificgeographic location. If it is determined that the access mode is WiFi,the algorithm proceeds to 322 where the OTT client is maintained.Otherwise, the algorithm proceeds to 320, where the OTT clientde-registers because the VoLTE client, such as VoLTE client 112, hasregistered. In addition, the handset can “permanently” de-register theOTT client, such as by setting a suitable state variable or in othersuitable manners.

Although algorithm 300 is shown in flow chart format, one of ordinaryskill will understand that object oriented programming, state transitiondiagrams or other suitable programming paradigms can also oralternatively be used.

FIG. 4 is a diagram of an algorithm 400 for registering a VoLTE clientor a VoWiFi client when an OTT client has already registered and is on avoice call, in accordance with an exemplary embodiment of the presentdisclosure. Algorithm 400 can be implemented in hardware or a suitablecombination of hardware and software.

Algorithm 400 can be used when a client such as OTT client 110 hasalready registered and is on a call, and the native VoLTE client orVoWiFi client enters into LTE coverage or trusted WiFi coverage.Algorithm 400 identifies the associated system components, andalgorithmic processes that are performed by those system components,using algorithms implemented in hardware or a suitable combination ofhardware and software. The diagram is exemplary, and other suitablesteps, processes, procedures or applications can be utilized inconjunction with the associated process steps.

Algorithm 400 begins at 402, where a client application is initiated anda network access type is determined, such as an LTE or WiFi network. Inone exemplary embodiment, a system such as system 100 can be utilized,and a device such as handset 102 using OTT client 110, carrier corenetwork 118, business support systems 126, operation support system 128or other suitable system components as described herein can be used todetermine the network access type, or other suitable processes can alsoor alternatively be used. The algorithm then proceeds to 404.

At 404, the client application registers with the mobile network andsubscribes to a registration event to get network notifications. In oneexemplary embodiment, the subscription can be performed using carrierOTT server 116, carrier core network 118, business support systems 126,operation support system 128 or other suitable system components asdescribed herein. The algorithm then proceeds to 406.

At 406, it is determined that no VoLTE client or VoWiFi client hasregistered for the same user, such as using handset 102, carrier corenetwork 118, business support systems 126, operation support system 128or other suitable system components as described herein, and thealgorithm proceeds to 408, where the registration is maintained. Thealgorithm then proceeds to 410.

At 410, the end user enters into a call with the OTT client. In oneexemplary embodiment, the end user can place a call with the OTT client.In another exemplary embodiment, the end user can be called by a remoteuser using the OTT client, or other suitable processes can also oralternatively be used. The algorithm then proceeds to 412.

At 412, the handset is moved into an LTE coverage area or a trusted WiFicoverage area, which can trigger the VoLTE client or the VoWiFi clientto register, respectively. After the registration process is initiated,the algorithm proceeds to 414.

At 414, the network sends a registration event, which also notifies theOTT client that the other client (the VoLTE client or the VoWiFi client)has initiated registration, such as by using carrier OTT server 116,carrier core network 118, business support systems 126, operationsupport system 128 or other suitable system components as describedherein. The algorithm then proceeds to 416.

At 416, the mobile network determines that the call should be allowed tocontinue, such as using carrier OTT server 116, carrier core network118, business support systems 126, operation support system 128 or othersuitable system components as described herein. In one exemplaryembodiment, the local network can determine whether a class of serviceallows the call to continue to completion, or other suitable processescan also or alternatively be used. The algorithm then proceeds to 418.

At 418, it is determined whether the client that is attempting toregister is a VoLTE client 112 or VoWiFi client 114 of handset 102, orother suitable native voice clients can also or alternativelyregistered, and this can be determined at handset 102, carrier corenetwork 118, business support systems 126, operation support system 128or other suitable system components as described herein. If it isdetermined that the client is a VoWiFi client, the algorithm proceeds to420 where the OTT client de-registers. Otherwise the algorithm proceedsto 422.

At 422, it is determined whether the native voice client, such as OTTclient 110, is using LTE access or WiFi access. Likewise, other suitabledeterminations can be made, based on the type of wireless accessavailable at the time or in the specific geographic location. If it isdetermined that the access mode is WiFi, the algorithm proceeds to 424where the OTT client is maintained. Otherwise, the algorithm proceeds to426, where the OTT client de-registers and the registered VoLTE clientis used. In addition, the handset can “permanently” de-register the OTTclient, such as by setting a suitable state variable or in othersuitable manners.

Although algorithm 400 is shown in flow chart format, one of ordinaryskill will understand that object oriented programming, state transitiondiagrams or other suitable programming paradigms can also oralternatively be used.

FIG. 5 is a diagram of an algorithm for supporting a transition from anative VoLTE client to an OTT client as a result of a coverage change,in accordance with an exemplary embodiment of the present disclosure.

Algorithm 500 can be used when a native VoLTE handset without VoWiFicapability moves out of the LTE coverage area into the WiFi coveragearea. In this scenario, the OTT client acts like the native VoWiFiclient. Algorithm 500 includes an identification of the associatedsystem components, and algorithmic processes that are performed by thosesystem components, using algorithms implemented in hardware or asuitable combination of hardware and software. The diagram is exemplary,and other suitable steps, processes, procedures or applications can beutilized in conjunction with the associated process steps.

Algorithm 500 begins at 502, where a handset is located in an LTEcoverage area. The algorithm proceeds to 504.

At 504, the handset is set to use the native VoLTE client, such as byhandset 102, carrier core network 118, business support systems 126,operation support system 128 or other suitable system components asdescribed herein. The OTT client de-registers, and a flag can be set orother suitable processes can be used to never register the OTT clientover LTE during the handset lifetime. The algorithm then proceeds to506.

At 506, the native VoLTE client is selected as the default client toreceive and make a voice call, such as by handset 102, carrier corenetwork 118, business support systems 126, operation support system 128or other suitable system components as described herein. In oneexemplary embodiment, the voice call can be a call that is initiated bythe user, but the call can also be an incoming call that is received bythe user or other suitable processes can also or alternatively be used,such as three-way or conference calling. The algorithm then proceeds to508.

At 508, the handset enters a trusted WiFi coverage area. In oneexemplary embodiment, the transition can be initiated when the trustedWiFi coverage area has a stronger signal strength than the LTE signalstrength, when the trusted WiFi coverage area is greater than a minimumlevel for a predetermined period of time, or in other suitable manners.The algorithm then proceeds to 510.

At 510, the OTT client is triggered to register into the network, andbecomes the default voice client. In one exemplary embodiment, thetransition to the WiFi network can include a command to handset 102,carrier core network 118, business support systems 126, operationsupport system 128 or other suitable system components as describedherein, to register the OTT client, or other suitable processes can alsoor alternatively be used. The algorithm then proceeds to 512.

At 512, the native VoLTE client disconnects or is de-registered, such asby handset 102, carrier core network 118, business support systems 126,operation support system 128 or other suitable system components asdescribed herein. In one exemplary embodiment, the transition to theWiFi network can include a command to disconnect or de-register theVoLTE client, such as using a command executed by the handset, a commandgenerated by carrier controlled environment 104 or in other suitablemanners.

Although algorithm 500 is shown as a flow chart, the algorithm can beimplemented using an objected-oriented process, a state diagram, orother suitable processes. The text portions of the process areincorporated by reference into this disclosure for all purposes.

FIG. 6 is a diagram of an algorithm 600 for processing an incoming callwhen a native VoLTE client enters into an LTE service area and an OTTclient is engaged in a call, in accordance with an exemplary embodimentof the present disclosure.

In one exemplary embodiment, when the native VoLTE client has registeredthrough LTE access and the OTT client has registered through WiFi accessand been in a call, the following exemplary algorithm can be used toprovide a co-existence mechanism. The algorithm includes anidentification of the associated system components, and algorithmicprocesses that are performed by those system components, usingalgorithms implemented in hardware or a suitable combination of hardwareand software. The diagram is exemplary, and other suitable steps,processes, procedures or applications can be utilized in conjunctionwith the associated process steps.

Algorithm 600 begins at 602, where the OTT client registers over atrusted WiFi network and subscribes to a registration event to get anetwork notification, such as by using handset 102, carrier core network118, business support systems 126, operation support system 128 or othersuitable system components as described herein. The algorithm thenproceeds to 604.

At 604, the network sends a registration event, such as from carriercore network 118, business support systems 126, operation support system128 or other suitable system components as described herein to handset102 or other components. The algorithm then proceeds to 606.

At 606, the end user enters a call using the OTT client, such as byusing handset 102, carrier core network 118, business support systems126, operation support system 128 or other suitable system components asdescribed herein. The algorithm then proceeds to 608.

At 608, the handset enters an LTE coverage area, and the VoLTE client isregistered, such as by handset 102, carrier core network 118, businesssupport systems 126, operation support system 128 or other suitablesystem components as described herein. The algorithm then proceeds to610.

At 610, an incoming call is received over the LTE network. In oneexemplary embodiment, the incoming call can be processed using the LTEnetwork in conjunction with carrier core network 118, business supportsystems 126, operation support system 128 or other suitable systemcomponents as described herein. The algorithm then proceeds to 612.

At 612, it is determined whether the VoLTE call or the WiFi call has ahigher priority. In one exemplary embodiment, this determination can bemade by handset 102, carrier core network 118, business support systems126, operation support system 128 or other suitable system components asdescribed herein. If it is determined that the VoLTE call has a higherpriority, the algorithm proceeds to 614 where the WiFi call isterminated. Otherwise, the algorithm proceeds to 616 and the user makesa selection as to which call to participate in, such as in response to aprompt that is generated during the call, in response to an accountsetting or in other suitable manners.

Although the process is shown as a flow chart, the process can beimplemented in other suitable manners, such as using anobjected-oriented process, a state diagram, or other suitable processes.The text portions of the process are incorporated by reference into thisdisclosure for all purposes.

It should be emphasized that the above-described embodiments are merelyexamples of possible implementations. Many variations and modificationsmay be made to the above-described embodiments without departing fromthe principles of the present disclosure. All such modifications andvariations are intended to be included herein within the scope of thisdisclosure and protected by the following claims.

1-20. (canceled)
 21. User equipment that is configured to: receive anindication that an internet protocol (IP) multimedia core networksubsystem (IMS) voice is unsupported over a 3G network, but is supportedover a non-3G network in a first communication system; register to anIMS server via the non-3G network in the first communication system; andperform the IMS voice over the non-3G network in the first communicationsystem.
 22. The user equipment of claim 21, wherein the user equipmentis further configured to: switch to a second communication system when avoice over long term evolution (VoLTE) is set to the secondcommunication system; register to the IMS via the non-3G network in thefirst communication system; and switch to the first communication systemfrom the second communication system.
 23. The user equipment of claim22, wherein the first communication system is a WiFi system and thesecond communication system is one of: a fourth generation (4G) system;a third generation (3G) system; or a second generation (2G) system. 24.The user equipment of claim 22, wherein the first communication systemis a WiFi system and the second communication system is one of: a thirdgeneration (3G) system; or a second generation (2G) system.
 25. The userequipment of claim 21, wherein when the first communication system is aWiFi system, the user equipment is further configured to: remain in theWiFi system; register to the IMS over the non-3G network in the WiFisystem; and perform an IMS voice over packet switch session over thenon-3G network in the WiFi system.
 26. The user equipment of claim 21,wherein when the first communication system is a WiFi system, the userequipment is further configured to: remain in the WiFi system; registerto the IMS over the non-3G network in the WiFi system; and perform theIMS voice over the non-3G network in the WiFi system.
 27. The userequipment of claim 26, wherein the user equipment performing the IMSvoice over the non-3G network in the WiFi system, is further configuredto: select a WiFi calling for the IMS voice call when a management isset to WiFi; and select a circuit switched fallback for a circuitswitched voice call when the management is set to cellular.
 28. A methodof voice domain selection, comprising: receiving, by a processingcircuitry of a user equipment (UE), an indication that an internetprotocol (IP) multimedia core network subsystem (IMS) voice isunsupported over a 3G access, but is supported over a non-3G access in afirst communication system; registering to an IMS via the non-3G accessin the first communication system; and performing the IMS voice over thenon-3G access in the first communication system.
 29. The method of claim28, further comprising: switching to a second communication system whenmanagement is set to the second communication system; registering to theIMS via the non-3G access in the first communication system; andswitching to the first communication system from the secondcommunication system.
 30. The method of claim 29, wherein the firstcommunication system is a WiFi system and the second communicationsystem is one of: a fourth generation (4G) system; a third generation(3G) system; or a second generation (2G) system.
 31. The method of claim29, wherein the first communication system is a WiFi system and thesecond communication system is one of: a third generation (3G) system;or a second generation (2G) system.
 32. The method of claim 28, when thefirst communication system is a WiFi system, further comprising:remaining in the WiFi system; registering to the IMS over the non-3Gaccess in the WiFi system; and perform an IMS voice over packet switchsession over the non-3G access in the WiFi system.
 33. The method ofclaim 28, when the first communication system is a WiFi system, furthercomprising: remaining in the WiFi system; registering to the IMS overthe non-3G access in the WiFi system; and performing the IMS voice overthe non-3G access in the WiFi system.
 34. The method of claim 33,wherein performing the IMS voice over the non-3G access in the WiFisystem, further comprising: selecting a WiFi calling for the IMS voicecall when a management is set to WiFi; and selecting a circuit switchedfallback for a circuit switched voice call when the management is set tocellular.
 35. A non-transitory computer readable medium storinginstructions which, when executed by a processor, cause the processor toperform the steps of: receiving an indication that an internet protocol(IP) multimedia core network subsystem (IMS) voice is unsupported over a3G access, but is supported over a non-3G access in a firstcommunication system; registering to an IMS via the non-3G access in thefirst communication system; and performing the IMS voice over the non-3Gaccess in the first communication system.
 36. The non-transitorycomputer readable medium of claim 35, wherein the instructions beingexecuted by a processor, further cause the processor to perform thesteps of: switching to a second communication system when management isset to the second communication system; registering to the IMS via thenon-3G access in the first communication system; and switching to thefirst communication system from the second communication system.
 37. Thenon-transitory computer readable medium of claim 35, wherein theinstructions being executed by a processor when the first communicationsystem is a WiFi system, further cause the processor to perform thesteps of: remaining in the WiFi system; registering to the IMS over thenon-3G access in the WiFi system; and performing an IMS voice overpacket switch session over the non-3G access in the WiFi system.
 38. Thenon-transitory computer readable medium of claim 35, wherein theinstructions being executed by a processor when the first communicationsystem is a WiFi system, further cause the processor to perform thesteps of: remaining in the WiFi system; registering to the IMS over thenon-3G access in the WiFi system; and performing the IMS voice over thenon-3G access in the WiFi system.
 39. The non-transitory computerreadable medium of claim 38, wherein the instructions being executed bya processor, further cause the processor to perform the steps of:selecting a WiFi calling for the IMS when a management is set to WiFi;and selecting a circuit switched fallback for a circuit switched voicecall when the management is set to cellular.